-
Notifications
You must be signed in to change notification settings - Fork 519
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce Passthrough Response type #300
Conversation
@jessicayuen This is a POC for conveying my thoughts on #299 . Let me know what you think |
Signed-off-by: Jyoti Mahapatra <jmahapatra@lyft.com>
@jessicayuen PTAL. Once it looks good to you, we can ask Kuat to take a look next. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, just a few minor comments:
Signed-off-by: Jyoti Mahapatra <jmahapatra@lyft.com>
@kyessenov Please take a look. |
Signed-off-by: Jyoti Mahapatra <jmahapatra@lyft.com>
@kyessenov Let us know what you feel about the change. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay. Makes sense to me. (I didn't review the tests.) Just a small typo I saw.
#299
While implementing envoyproxy/xds-relay#85 , we realized that go-control-plane always marshals the response. As a result, we were not able to send an existing DiscoveryResponse as a passthrough.
This PR introduces a new PassthroughResponse struct , which is not subjected to any marshalling while sending the response on the watches.